![Looker Blocksを使ってFirebaseのデータを5分で可視化してみた](https://devio2023-media.developers.io/wp-content/uploads/2023/06/looker-in-google_1200x630.png)
Looker Blocksを使ってFirebaseのデータを5分で可視化してみた
奈良県でリモートワーク中の玉井です。
今回は、何かとややこしい構造をしている(BigQueryにエクスポートした)Firebaseデータを、Lookerで楽に可視化します。
Firebase(のデータ)を分析するのは大変?
昨今、スマホアプリ等のデータを分析してマーケティング等に役立てる…ということは当たり前になってきています。そして、そこに出てくるものとして、メジャーなサービスの一つがFirebaseでしょう。Firebaseを使って開発しているスマホアプリやWebアプリは多いと思います。
FirebaseのデータはGoogle BigQueryにエクスポートし、SQLを使って分析をがんばっている方はたくさんいるかと思います。…が、BigQueryにエクスポートしたFirebaseデータの構造は結構クセがあり、正直扱いづらいですよね(日単位でテーブルが生成される、めっちゃ入れ子になっている等)。
そこでLookerです。実は、Firebase用のBlocksが用意されています。Firebaseのややこしいデータをキレイに構造化してくれるLookMLが既に定義されているため、これを利用すると、すごい簡単にFirebaseのデータを可視化(及び分析)することができます。
というわけで、実際にやってみたいと思います。
やってみる前の準備や環境などについて
使用データ
Firebaseは「モバイル・Webアプリケーション開発プラットフォーム」…データを用意するにしても、何かアプリを開発しないとダメなのでは…そんなふうに考えていた時期が俺にもありました。
Google様をなめてはいけません。簡単にBigQuery上に用意できるFirebaseのサンプルデータがあります!
上記のリンクからポチポチするだけで、すぐにサンプルデータをBigQuery上に用意することができました。
確かにこれは(分析するには)ちょっと厄介な構造ですね。
事前準備
LookerにBigQueryをConnectionとして登録しておく
下記を参考に準備しておきます。
API
Looker APIも使うので、使用できるようにしておきます。
その他操作環境
- Looker 7.10.19
- firebase_block_v3
やってみた
Projectを新規作成する
Starting PointでClone Public Git Repositoryを選ぶのがポイントです。これを選ぶと、既にLookMLが展開されているリポジトリをインポートしてProjectを作ることができるのですが、今回は冒頭に記載したFirebaseのBlocks(のリポジトリ)を指定してインポートします。
LookMLをちょっとだけ修正する
Blocksですので、もうほとんどLookMLが完成しています。ただし、初期のままだと動かない部分があるので、自分の環境に合わせて修正する必要があります。
ModelファイルのConnectionの部分
firebase.model
の1行目は下記のようになっています。Connectionの名前を修正しましょう。
connection: "firebase-sample"
Modelファイルのincludeのコメントアウト部分
firebase.model
のincludeの一部は下記のようにコメントアウトされています。
# include: "my_dashboard.dashboard.lookml"
このままでは、既に用意されているダッシュボードが見れないので、下記のように修正します。「ダッシュボードは自分でゼロから作る」という場合は、この作業は不要です。
include: "firebase.dashboard"
付属のNotebookを使ってイベントとユーザープロパティのViewを生成する
何のスマホアプリだろうがWebアプリだろうが、Firebaseを使っている以上、データの構造は同じです(だからBlocksを構築して配布することができる)。
しかし、イベントの種類やユーザープロパティは、そのアプリケーション毎に異なるはずです。それらも合わせて分析したい場合、これら独自のデータもLookMLに定義する必要があります。
これらは手動で書く必要があるのか…と思うところですが、そんなことはありません。Blocksには、ipynbファイル…要するにPythonコードも入っており、こちらを実行するだけで、ユーザープロパティ等を定義したViewファイルを生成することができます。
実行場所はどこでもいいのですが、私はGoogle Colabを使いました。下記は実際に実行した結果です。ちなみに、実行する過程でLooker APIのクライアントID等を入力する必要があるので、準備しておきましょう(下記画像にうつっているID等はサンプルのものです)。
見ればわかるように、Viewファイル自体が出力されるので、それを同Viewに貼り付ければOKです(events_generated.view
とuser_properties_generated.view
)。今回はサンプルデータなので新しいdimension等は一切でてきませんでしたが…。
ダッシュボードを見てみる
ダッシュボードを見るまでの作業はここで終了ですので、ダッシュボードを見てみましょう。
いい感じに可視化できていますね!
タイルの中をちょっと見てみる
右下のプラットフォーム別リテンションというグラフをExploreで見てみます。
Lookerが生成しているクエリはこちら。とても手で書こうとは思いません。
Blocksの構造について
どういうLookMLでこれらのクエリが生成されているのか…。コード自体は冒頭のGithubページから見ることができます(UNNESTが駆使されていることがわかります)。
ここでは、全体の構造だけちょこっと見ておきます。
まず、Project全体は下記の通り。実はファイルはそんなに多くありません。
付属のPythonコードから生成するView
まず、2つのViewがあります。
events_generated.view
user_properties_generated.view
これは、先程のPythonコードで生成するViewファイルです。独自のイベントやユーザープロパティを定義するViewですね。
event.view
そして、これをextendsしているevents.view
があります。上記のユーザープロパティ等を継承しつつ、Firebase共通のデータについて一通り定義してあります。コメントやgroup_labelで項目がグルーピングされていたり、descriptionがしっかり書かれていたり、何かとわかりやすくしてくれてあります。
session.view
セッションの定義や計算が行われているViewです。
永続派生テーブルが使用されています。この中のクエリについては、下記が参考にされているようです。
firebase.model
定義されているExploreは1つだけ。ベースはevent.view
となっており、それに対して、項目をUNNESTでバラしたものをいくつかJOINしている形になります。最後にsession.view
もJOINされています。
基本的に、このExploreで大体の分析はできるかと思いました。
おわりに
Firebaseの分析に四苦八苦されている方は、ぜひLookerとこのBlocksを試していただきたいですね。